The present invention relates to graphical user interfaces, and more particularly, to techniques for displaying information and providing user interaction with respect to various types of data such as structured and unstructured data.
Prior art software applications are limited in several respects. For example, when a user requires both structured and unstructured information, prior art software applications often take the approach of providing the structured information in one window, and the unstructured information in a different window. This is particularly true in business software applications that involve presenting structured information from a big “back-end” enterprise application (referred to herein as an “ERP” system) along with unstructured information in the form of “attached documents” (such as images of original source documents, that may have been scanned or faxed in or received via other electronic means). Structured information is typically displayed in one window, and if the user wants to review the unstructured information (e.g., the original document, an “attachment”), they click on a link to open the original document (the “attachment”) in another window. This two-window approach leads to several problems. First, it can be difficult to review both the structured and unstructured information at the same time, difficult to compare the two, and difficult to get the “complete” picture at one time. Second, users often do not bother to open and review the unstructured information, either because it is a “hassle” or because they are not forced to do so (software applications typically allow the user to simply interact with the transaction in the “structured” window, only reviewing the unstructured information in the attachment if they choose to). This leads to less informed decisions, and in scenarios involving the review and approval of transactions can allow users to approve transactions that they have not fully reviewed.
Another prior art limitation can be seen when users are presented with unstructured information (such as images of business documents that were originally in paper format and have subsequently been scanned into images or faxed into a system). Such users often need to be able to manipulate the unstructured information in order to properly view and review it. For example, typical user display screens often require that a user zoom in on an image to be able to read the text on the image of the document, or pan and scroll around the document once it is zoomed in, or rotate the image of the document to read information that may have been in a different orientation, or flip to another page of the document. When software applications allow users to manipulate unstructured information (such as document images) in this fashion, they frequently require that special software be installed on the user's computer. This software may be in various forms (from “native” applications (such as a “Windows” executable on the “Windows” operating system), to browser “plug-ins”, to “Java” programs, to “ActiveX” controls, to “Javascript” and more). The problem with this approach is that installing such software on a user's computer is often problematic or undesirable for several reasons, such as:                1. Security concerns—downloaded software may introduce computer viruses or “spy-ware.”        2. Involvement of IT (Information Technology) department—configuration control policies can make it difficult or impossible to download software. For example, the user's desktop may be “locked down” and not allow users to install software locally without proper authorization. The software download consequently requires coordination and/or assistance with the IT department, and subsequent support to deal with issues that arise.        3. Configuration problems/conflicts—problems may arise due to the interaction of the downloaded software with other programs and software on the user's computer.        
4. System instability—over time, as other software programs are installed, operating system or web browser patches or upgrades are applied, thus degrading or disabling the application software.                5. Platform limitations—compatibility limitations may exist with various platform components, such as operating systems, operating system versions, web browser types, web browser versions, etc. Also, the requirement to install software in order to access the application limits the number and types of devices from which the application can be accessed. For example, Internet accessible cell phones or PDAs are typically unavailable as points of access unless the software has been specifically designed to work on the given device.        6. Accessibility issues—the user is typically only able to access the application if they have first installed the required software, something that they may not have the authorization, ability—or time—to do on given computer. For example, a user may wish to access a particular application while at a public Internet kiosk at an airport or an Internet cafe. However, the user may not have the time or authority (or both) to first install the required software on the given computer.        
It is often useful for users to be able to annotation or “mark up” an image of a document, by placing annotations directly onto the image of the document itself, for subsequent viewing by themselves or by other users. However, when this capability is provided to users in prior art systems, it typically requires the installation of special software on the user's computer. This approach has all of the same problems identified above.
In prior art systems, when software applications present both unstructured information (such as images of documents) and structured information to a user, often the structured information is not “live” or “real time” information from the true, definitive source of that information. Rather, this information is typically either a “copy” that is prone to becoming “stale” (i.e., out of date and inaccurate), or isn't even from the definitive source of that information (e.g., it may be from a second computer system, such as the “indexing” data entered into a document imaging system, rather than the actual data from the definitive source—the company's “ERP” system). Both of these approaches have problems, such as:                1. Users can be, and often are, viewing information that is “out of date” and inaccurate.        2. Because two copies of the data exist (one in the ERP system and one in the application), it becomes easy for the copies of the data to get “out of sync”        3. Because two copies of the data exist, extra effort is typically required to enter information into these two separate systems.        4. Since extra effort is involved to enter data into the two separate systems, typically only a subset of the full amount of data is entered into the application, and therefore only that subset of the full amount of data is available for display to the user in the application.        
Prior art systems often lack real-time validation of data. When applications of prior art systems allow the user to enter data, they often don't validate this entered data in real-time against the definitive source of validation, such as a back-end ERP system. This requires extra subsequent steps to either manually verify the data or resolve problems occurring from data that subsequently fails validation against the definitive system, such as the ERP system.
Prior art systems typically do not provide substantial interaction with back-end ERP systems. When applications allow users to take actions (such as “approving” a vendor invoice, for example), the result is often that another person must then manually update the back-end ERP system to reflect the fact that the original user has taken the particular action. This is problematic for several reasons. On the one hand, extra effort required. Further, the procedure introduces opportunities for accidental error. Also, the procedure is not an automated, controlled process. For example, the second (updating) person may not accurately reflect the decision of the first person (the user).
Prior art systems do not provide a user with a context-sensitive display of information. Typically, the information displayed to a user is “fixed” in nature—that is, all users typically see the same information, regardless of the state of the particular business process, regardless of who they are, and any number of other factors. With this approach, too much data may be presented to a given user (more data than they will bother to review). Further, insufficient data may be presented to a given user (for example, at times only data that is common across all scenarios is displayed). Also, inappropriate data may be presented to a given user (possibly violating security or information access policies).
Similarly, prior art systems do not provide context-sensitive instructions. “Casual” users are often unsure of why they are being asked to review a given transaction, what their options are, and how to go about taking one of those options or actions. Generic and static instructions are sometimes provided, however these are often not helpful enough to allow a given user to be able to understand what they are being asked to do, why, and how to do it.